ETH2.0: Phase 2

Resources

Introduction of "execution script (environment)"

A layer-1-minimizing phase 2 state execution proposal, @ethresear.ch, 2019.05, vbuterin

The basic idea: contracts as a base-layer concept exist only on the beacon chain, and ETH only exists on the beacon chain ETH can be held by either beacon chain contracts (also called “precompiles”) or by validator accounts)

However, shards continue to have their own execution and their own state.

A transaction on a shard must specify which precompile it calls, and the in-shard state transition function executes the specific beacon chain precompile code using the transaction as data, with the code execution having the ability to read and write from a region of the state of any shard reserved for that precompile and issue receipts.

Iterations

Proposed further simplifications/abstraction for phase 2, @ethresear.ch, 2019.05, vbuterin

Phase 2 Proposal 2 @HackMD

Alternate phase 2 architecture proposal @HackMD, 2019, Vitalik

There is no longer any notion of shard state; instead, a shard block only contains a blob of data, a reference to a on-beacon-chain pure function ID, and a reduction output.

The beacon chain now contains a full stateful state transition engine à la eth1.

Eth2 shard chain simplification proposal by Vitalik, 2019.10

Every shard has a state, which is a mapping ExecEnvID -> (state_hash, balance).

A shard block is split into a set of chunks, where each chunk specifies an execution environment.

The execution of a chunk takes as input the state root and the contents of the chunk (ie. a portion of the shard block data) and outputs a list of [shard, EE_id, value, msg_hash] tuples, maximum one EE_id per shard

In the shard block header, we put a “receipt root”, which contains a mapping shard -> [[EE_id, value, msg_hash]...]

Main benefit: easier fee markets

Cross-shard ETH transfers

Problem Definition

Cross-shard receipt and hibernation/waking anti-double-spending, @ethresear.ch, 2019.01, vbuterin

Implementing cross-shard transactions 2019.10, Vitalik

Solution: Replace the tree of consumed receipt IDs with the nonce of send/receive receipts by enforcing receipts to be processed sequentially

Will's comment on a "receipt bitfields" idea

Moving ETH between shards: the problem statement 2019.12, Vitalik

EE-based

A meta-execution environment for cross-shard ETH transfers 2019.12, Vitalik

An even simpler meta-execution environment for ETH 2019.12, Vitalik